Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix signal handler #2152

Merged
merged 2 commits into from
Nov 30, 2022
Merged

Fix signal handler #2152

merged 2 commits into from
Nov 30, 2022

Conversation

leaanthony
Copy link
Member

This PR sets up a new signal handler in C that overrides the current one (in C) so that SA_ONSTACK is used. When used against the nil dereference example @mholt gave, it appears to work as expected.

Closes #2134

@leaanthony leaanthony marked this pull request as ready for review November 30, 2022 07:59
@leaanthony
Copy link
Member Author

@stffabi - do you think this will conflict with your #2151 PR?

@leaanthony
Copy link
Member Author

@mholt - any chance you could try this against your original issue (before you fixed it)?

@stffabi
Copy link
Collaborator

stffabi commented Nov 30, 2022

Good question, I've moved the gtk_init to init() so that's the only thing I could think of that would interfere. But currently the fixup is also done after gtk_init so I think we should be fine.

Copy link
Collaborator

@stffabi stffabi left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM 🚀 , just added a minor comment.

if (sigaction(signum, NULL, &st) < 0) {
goto fix_signal_error;
}
st.sa_flags |= SA_ONSTACK;
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we skip fixup the signal handler if the SA_ONSTACK flag is already set?

Copy link
Member Author

@leaanthony leaanthony Nov 30, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No harm in installing this one over it i guess? We know that either gtk or webkit do install one without SA_ONSTACK so we should be good regardless.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah absolutely, would maybe just save some cycles for internal setting up the handler in the kernel when it's already fine.But that can be neglected 😄

@leaanthony leaanthony merged commit 7f8952e into master Nov 30, 2022
@leaanthony leaanthony deleted the bugfix/2134_linux_signal_errors branch November 30, 2022 09:37
@mholt
Copy link
Contributor

mholt commented Nov 30, 2022

@leaanthony I will try this out ASAP! Is it OK if I run with -skipbindings for now? (See Slack for the error I'm getting about -tsprefix otherwise)

@YOU54F
Copy link

YOU54F commented Jul 3, 2024

Thanks for this fix @leaanthony - This was helpful for me in solving a pesky bug in pact-go where we consume a rust shared library, in various languages including golang via cgo.

The issue only crops up where the rust shared library calls out to external plugins and manages their process lifecycle.

pact-foundation/pact-go#269

@leaanthony
Copy link
Member Author

I'm glad it was useful 🙏

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

fatal error: non-Go code set up signal handler without SA_ONSTACK flag
4 participants